Computer-implemented systems and methods to enable complex functionality on a blockchain while preserving security-based restrictions on script size and opcode limits

ABSTRACT

The invention relates to blockchain technologies such as the Bitcoin blockchain. The invention uses a novel technique to decompose the functionality of a blockchain transaction script into several chunks or functional parts, and to use the output of a chunk as the input of the next chunk. Advantageously, this allows the blockchain to be used for ever complex tasks and computations while minimising script size, and also provides a novel architecture for the distributed execution of computational processes. The invention comprises a method of using a plurality of blockchain transactions to execute a computer-implemented task, comprising the steps: using an unlocking script (ULS1) associated with a first input (In1) in a blockchain transaction (Tx2) to present at least one data item to a locking script (LS1) of another transaction (Tx1) so as to provide a result on a stack; amending the blockchain transaction (Tx2) to include a second input (In2); generating a further unlocking script (ULS2) associated with the second input (In2), the further unlocking script (ULS2) comprising the result from the stack; and presenting the further unlocking script (ULS2) to a further locking script (LS2) such that the result from the stack is provided as input to the further locking script (LS2). Preferably, the locking script (LS1) and the further locking script (LS2) are provided in association with different outputs within the same blockchain transaction (Tx1).

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/472,170, filed Jun. 20, 2019, which is a 371 National Stage ofInternational Patent Application No. PCT/IB2017/058007, filed Dec. 15,2017, which claims priority to United Kingdom Patent Application No.1621827.3, filed Dec. 21, 2016, and United Kingdom Patent ApplicationNo. 1621830.7, filed Dec. 21, 2016, and United Kingdom PatentApplication No. 1621831.5, filed Dec. 21, 2016, the disclosures of whichare incorporated herein by reference in their entirety.

This invention relates generally to blockchain technology, and moreparticularly to implementing complex functionality via the blockchain.Advantageously, the invention allows for the outcome of a computation orexecuted code to be transferred one to the other, providing a mechanismwhich uses blockchain transactions as a control mechanism for enabling,influencing and directing the activities of a computer-implementedprocess. The invention is particularly suited for, but not limited to,the implementation and control of automated processes.

In this document we use the term ‘blockchain’ to include all forms ofelectronic, computer-based distributed ledgers, including, but notlimited to blockchain and transaction-chain technologies, permissionedand un-permissioned ledgers, shared ledgers and variations thereof. Themost widely known application of blockchain technology is the Bitcoinledger, although other blockchain implementations have been proposed anddeveloped. While Bitcoin may be referred to herein for the purpose ofconvenience and illustration, it should be noted that the invention isnot limited to use with the Bitcoin blockchain and alternativeblockchain implementations and protocols fall within the scope of thepresent invention.

A blockchain is a consensus-based, electronic ledger which isimplemented as a computer-based decentralised, distributed system madeup of blocks which in turn are made up of transactions. Each transactionincludes at least one input and at least one output. Each block containsa hash of the previous block to that blocks become chained together tocreate a permanent, unalterable record of all transactions which havebeen written to the blockchain since its inception. Transactions containsmall programs known as scripts embedded into their inputs and outputs,which specify how and by whom the outputs of the transactions can beaccessed. On the Bitcoin platform, these scripts are written using astack-based scripting language. Scripts are made up of instructions(opcodes) which push data items onto the stack, or pop them off thestack.

In order for a transaction to be written to the blockchain, it must be“validated”. Network nodes (miners) perform work to ensure that eachtransaction is valid, with invalid transactions rejected from thenetwork. Software clients installed on the nodes perform this validationwork on an unspent transaction (UTXO) by executing its locking andunlocking scripts. If execution of the locking and unlocking scriptsevaluate to TRUE, the transaction is valid and the transaction iswritten to the blockchain. Thus, in order for a transaction to bewritten to the blockchain, it must be i) validated by the first nodethat receives the transaction—if the transaction is validated, the noderelays it to the other nodes in the network; and ii) added to a newblock built by a miner; and iii) mined, i.e. added to the public ledgerof past transactions.

Although blockchain technology is most widely known for the use ofcryptocurrency implementation, digital entrepreneurs have begunexploring the use of both the cryptographic security system Bitcoin isbased on and the data that can be stored on the Blockchain to implementnew systems. It would be highly advantageous if the blockchain could beused for automated tasks and processes which are not limited to therealm of cryptocurrency. Such solutions would be able to harness thebenefits of the blockchain (e.g. a permanent, tamper proof records ofevents, distributed processing etc) while being more versatile in theirapplications.

One area of current research is the use of the blockchain for theimplementation of “smart contracts”—machine executable programs whichact upon the conditions set out in machine-readable documents andcomprise rules that can process inputs in order to produce results,which can then cause actions to be performed dependent upon thoseresults.

However, as more and more sophisticated applications are devised forblockchain technology, so the need for ever-increasingly complex scriptfunctionality rises as well. A technical problem arises here, though, asblockchain technologies are purposefully designed to restrict and limitwhat can be legitimately achieved within a script. For example, due tosecurity considerations, the Bitcoin Script language is deliberatelynon-Turing complete. Furthermore, an upper limit of 200 op-codes isimposed per script so as to prevent Denial of Service attacks. As longas a Bitcoin transaction script contains fewer than 200 op_codes, it canbe validated and broadcasted. However, with the advent of moresophisticated program elements (e.g. primitives), this limit places arestriction the development of more complex technical solutions forapplications such as smart contract execution.

Thus, a technical solution is required which enables complexfunctionality to be built into blockchain scripts without compromisingsecurity and/or requiring any adaptation of the existing protocol.Preferably, this solution would allow the capabilities of existingblockchain protocols such as the Bitcoin protocol, to enable theinfrastructure to be used in novel and advantageous ways by usingblockchain transactions and the stack to extend the computationalabilities of the blockchain beyond its present limits. Such a techniquewould enable the use of transactions to control, influence and directthe execution of a technical process.

Such a solution has now been devised. The invention provides at leastthe advantages described herein.

The present invention is defined in the appended claims.

Therefore, in accordance with the invention there may be provided amethod and/or corresponding system.

According to one perspective, the invention may be viewed as providing atechnique and corresponding implementation which enables complexfunctions to be performed via the use of a blockchain. Advantageously,this technique may use a combination of a variety of distinct computingcomponents to perform the specified function. These may comprise one ormore software-based clients, at least one storage resource (preferably astack-based data structure), at least one digital wallet executing on atleast one processor and arranged to generate a blockchain transaction,and/or a blockchain. Preferably, this may be the Bitcoin blockchain.

Embodiments of the invention may involve the decomposition of atechnical task over multiple transactions and their respective inputsand outputs. Embodiments of the invention may obtain data from at leastone data storage resource and use that data to control the execution ofa task or computation which is implemented over multiple blockchaintransactions, in particular by passing script outputs between therespective transaction inputs and outputs.

The various system components mentioned above may be arranged so as toobtain and pass data items between the components so as to enablecomputations and tasks to be performed via the blockchain transactions.These computations/tasks can be lengthy and complex, and could not beperformed via blockchain transactions prior to the present invention,possibly due to an enforced limit on the size of the script and/ornumber of op_codes used therein.

Once the transactions are on the blockchain, they are recorded in animmutable and permanent manner. Therefore, from one perspective theinvention provides an improved blockchain protocol, improved blockchainclient, an improved computational technique and corresponding apparatus,and/or an improved process control mechanism.

In one sense, the invention enables complex computations to be performedvia a blockchain protocol while still preserving the security-basedrestrictions on script size and opcode limits. Prior to the invention,such lengthy computations would either be impossible using, for example,the current Bitcoin protocol or one would have to use an alternativeform of blockchain which does not include script-based restrictions. Thelatter is not always desirable or feasible. Thus, the invention providesan enhanced security mechanism. As it provides a means for achievingresults that were hitherto not possible via the protocol, the inventionprovides an improved blockchain protocol.

A method in accordance with the invention may be described as a methodof using a plurality of blockchain transactions to execute acomputer-implemented task. Additionally or alternatively, it may bedescribed as a method of:

-   -   controlling the execution of computer-implemented task by        allocating or distributing the execution of portions of the task        to locking and unlocking scripts provided in two or more        respective blockchain transactions;    -   controlling the execution of a computer-implemented task by        reading a value from a stack-based data structure and passing it        as a value from an unlocking script to a locking script.

The method may comprise the steps:

-   -   using an unlocking script (ULS1) associated with a first input        (In1) in a blockchain transaction (Tx2) to present at least one        data item to a locking script (LS1) of another transaction (Tx1)        so as to provide a result on a stack;    -   amending the blockchain transaction (Tx2) to include a second        input (In2);    -   generating a further unlocking script (ULS2) associated with the        second input (In2), the further unlocking script (ULS2)        comprising the result from the stack; and/or    -   presenting the further unlocking script (ULS2) to a further        locking script (LS2) such that the result from the stack is        provided as input to the further locking script (LS2).

The blockchain transactions may be arranged in accordance with a versionof the Bitcoin protocol.

The method may further comprise the step of:

performing one or more of the steps of claim 1 more than once.

The method may further comprise the step of:

using the at least one data item in the execution of a calculation orsequence of instructions provided within the locking script (LS1).

The method may further comprise the step of:

using the result provided on the stack in the execution of a calculationor sequence of instructions provided within the further locking script(LS2).

The method may further comprise the step of obtaining the result fromthe stack.

The method may further comprise the step of:

validating the blockchain transaction (Tx2) and/or the other transaction(Tx1) to generate the result on the stack.

The unlocking script (ULS1) and the further unlocking script (ULS2) maybe provided in association with different inputs (In1, In2) within thesame blockchain transaction (Tx2). The invention may be substantially asdescribed hereafter in respect of “embodiment 1” of the invention,and/or substantially in accordance with the technique or principlesillustrated by the examples shown in FIGS. 1 to 3, 9 a and 9 b.

The locking script (LS1) and the further locking script (LS2) may beprovided in association with different outputs within the sameblockchain transaction (Tx1). Advantageously, this provides a compactand efficient solution because only two transactions are required toimplement the functionality. This reduces space and storagerequirements, fees, processing overheads and other disadvantagesassociated with the propagation of multiple transactions.

The step of presenting the further unlocking script (ULS2) to a furtherlocking script (LS2) may provide a further result on the stack, or on adifferent stack. The stack may be the main stack or an alt stack.

The method may further comprise the step of: using a blockchain clientto obtain the result from the stack. The blockchain client may be aBitcoin client. It may be adapted, arranged or configured to be able toread, return and/or obtain a value from the stack.

The method may further comprise the step of:

submitting the blockchain transaction (Tx2) and/or other blockchaintransaction (Tx1) to the blockchain network.

The at least one data item is provided as metadata within the unlockingscript (ULS1). The result may be provided as metadata within the furtherunlocking script (ULS2).

The invention also comprises a corresponding system and apparatus. Theinvention may comprise a computer-implemented system arranged andconfigured to implement any preceding method step(s) mentioned above orsubstantially as described hereafter.

These and other aspects of the present invention will be apparent fromand elucidated with reference to, the embodiment described herein. Anembodiment of the present invention will now be described, by way ofexample only, and with reference to the accompany drawings, in which:

FIG. 1 illustrates the chain of transactions and the sequential stepsinvolved in a multiple inputs/outputs approach according to a firstembodiment of the invention.

FIG. 2 shows Transaction 1 (Tx1) according to an illustrative version ofa first embodiment of the invention.

FIG. 3 shows Transaction 2 (Tx2) according to an illustrative version ofa first embodiment of the invention.

FIG. 4 shows an illustrative chain of transactions according to anillustrative version of embodiment 2

FIGS. 5 to 8 show transactions 1, 2, 3, and 4 in accordance with anillustrative version of embodiment 2.

FIGS. 9 a and 9 b show illustrations of how an example version of theinvention may be provided in accordance with embodiment 1.

FIG. 10 shows a simple illustration of a blockchain client being used toobtain an item left on top of the stack.

ILLUSTRATIVE EMBODIMENTS OF THE INVENTION

In the following examples, we shall use Bitcoin as our illustrativeblockchain implementation and protocol, because it is the most widelyknown. This is for the purposes of illustration only and it should benoted that the invention is not limited in this regard. Other blockchainimplementations will also fall within the scope of the invention.

In order to prevent deployment of DoS (Denial of Service) attacks, thedefault Bitcoin client sets a limit on the maximum number of bytes andop_codes that can be include in a valid script. As it stands at thepriority date of the present application, this limit is 10,000 bytes and201 op_codes. Any script comprising more than 201 op-codes or 10,000bytes will not be valid. While imposed for worthwhile reasons, thisrestriction hampers the development of more sophisticated scriptfunctionality and, therefore, the complexity of the technical solutionsthat can be designed to operate in conjunction with blockchaintechnology.

The present invention provides two techniques (embodiments) which enableusers to split blockchain scripts into multiple inputs/outputs via theuse of two or more blockchain transactions. Both embodiments may rely onthe capability of automated computing agents (or “bots”) which areconfigured to:

-   -   read the state of the stack,    -   propagate i.e. communicate the result(s) of executed script(s)        to the input(s) of unspent transaction output(s),    -   split up large complex scripts into multiple smaller, simple        units.

It should be noted that in some blockchain implementations, such asBitcoin, a custom client may be required to enable the state of thestack to be read after a script has terminated, as the default Bitcoinclient does not provide access to this item of information. The stack isrepresented as a list in a .cpp file, which is included in the bitcoincore program. By inserting a few lines of code into the class whichemulates the stack behaviour, it is possible to obtain and returninformation contained in the list. The information can then be passed onfor use by another computing resource and/or in another computation.This is shown in FIG. 10 .

The propagation of the result of the executed script does not requireany automation and could be performed manually (at least in principle).However, in a typical implementation it is expected that externalsystems such as compilers would handle the automation of the operationsinvolved in splitting complex scripts.

Advantageously, no modification of the Bitcoin protocol is required bythe present invention. In other words, while a custom client may beneeded to prepare the transaction(s), once the transactions have beenbroadcast, all nodes of the Bitcoin network will be able to validatethem.

Thus, in accordance with (all versions of) the invention, the underlyingconcept is to split the script into several chunks or functional parts,and to use the output of a chunk as the input of the next chunk. This isan important deviation from the prior art. It allows the blockchain tobe used for ever complex tasks and computations while preserving thelimit on script size, and provides a novel architecture for thedistributed execution of computational processes.

However, it must be kept in mind that the ultimate outcome of theexecution of a script is binary, i.e. either the transaction is markedinvalid or it is marked valid (assuming that it satisfies also the otherrequirements). Therefore, in order to “connect” the outputs of one chunkof computation with the inputs of the next chunk of computation one mustuse to a non-reference client that can access the values on the stackand reuse them, as explained above.

We start with the following simple example:

x+y>3

which can be written in terms of OP codes in the following way:

-   -   OP_<x> OP_<y> OP_ADD OP_3 OP_GREATERTHAN

We split this into the following two chunks:

z=x+y

z>3

In accordance with a first approach, a solution could be adopted as nowdescribed.

Alice prepares Tx1 as follows:

Tx1

In0:

-   -   amount: A+<dust>+tf    -   ref: . . .    -   unlocked by: . . .

Out1:

-   -   amount: <dust>    -   locked by: OP_ADD OP_SWAP <Bob's pubKey> OP_SWAP OP_CHECKSIG        OP_DROP

Out2:

-   -   amount: A    -   locked by: OP_3 OP_GREATERTHAN OP_SWAP <Bob's pubKey> OP_DROP

Now Bob begins to prepare Tx2 in the following way:

Tx2

In0:

-   -   amount: tf    -   ref: . . .    -   unlocked by: . . .

In1:

-   -   amount: <dust>    -   ref: Tx1:Out1    -   unlocked by: <Bob's signature> OP_2 OP_3

Out0:

-   -   amount: <dust>    -   locked by: . . .

Bob will now sign the transaction, validate it, and (use the customisedclient to) read from the stack the output of the unlocking script ofTx2:In1 chained with the unlocking script of Tx1:Out1.

He will then proceed to alter Tx2 by adding the following input andoutput:

In2:

-   -   amount: A    -   ref: Tx1:Out2    -   unlocked by: <Bob's signature> OP_5

Out1:

-   -   amount: A    -   locked by: . . .

where obviously OP_5 is the result of the first chunk of thecomputation. Also in this case, one could use multi-signatures toprevent Bob from broadcasting a transaction within which OP_5 isreplaced with something else. This approach has the advantage that alarge number of chunks (up to the limit on the number of inputs andoutputs in a transaction) can be chained using only two transactions.Therefore, complex functionality and computation can be performed in anefficient manner, requiring only two transactions to be validated andmined by the blockchain network, and using minimal storage requirementson the blockchain.

In accordance with an alternative approach the following steps could betaken.

The first transaction Tx1 is prepared and jointly signed by all theowners of the inputs. Inputs are sent to Alice's public key using thefollowing locking script:

-   -   OP_ADD OP_SWAP <Alice's pubKey> OP_SWAP OP_CHECKSIG OP_DROP

Tx1

In:

-   -   amount: A+tf    -   ref: . . .    -   unlocked by: . . .

Out1:

-   -   amount: A    -   locked by: OP_ADD OP_SWAP <Alice's pubKey> OP_SWAP OP_CHECKSIG    -   OP_DROP

Alice will now prepare Tx2 in the following way:

Tx2

In1:

-   -   amount: 2*<dust>+tf    -   ref: . . .    -   unlocked by: . . .

In2:

-   -   amount: A    -   ref: Tx1:Out1    -   unlocked by: <Alice's signature> OP_2 OP_3

Out1:

-   -   amount: <dust>    -   locked by: . . .

where Tx2:In2 will be now signed with the flag SIGHASH_NONE, so thatother outputs can be added. As known in the art, SIGHASH_NONE is aBitcoin signature hash type which signs only inputs. Therefore, whenSIGHASH_NONE is used, anyone is able to modify the outputs in any mannerthat they choose.

Tx2:In1 presumably references Alice's funds and can be unlocked withSIGHASH_SINGLE so that, again, other outputs can be added. In thecurrent form, the transaction will transfer amount A as transactionfees. However, Alice does not broadcast the transaction in the currentform, but simply verifies it locally. In the verification process theunlocking script of Tx2:In2 will be executed together with the lockingscript of Tx1:Out:

-   -   <Alice's signature> OP_2 OP_3 OP_ADD OP_SWAP <Alice's pubKey>        OP_SWAP OP_CHECKSIG OP_DROP        and at the end of the execution of the stack the remaining        result will be 5, i.e. the result of the first chunk of        computation. Alice's custom Bitcoin client will now save or        record the result of the first chunk of computation and modify        Tx2 by adding the following two outputs:

Out2:

-   -   amount: A    -   locked by: OP_3 OP_GREATERTHAN OP_SWAP <Bob's pubKey> OP_DROP

Out3:

-   -   amount: <dust>    -   locked by: OP_RETURN OP_5

but she will sign Tx2's inputs again, this time with the usual flagSIGHASH_ALL, so that now none of the outputs of the transaction can bemodified. Bob can now complete the computation by reading the datastored in Out3 after OP_RETURN.

As known in the art, OP_RETURN is a Bitcoin OP CODE which can be used tomark a transaction output (TxO) as invalid. Any data provided afterOP_RETURN is ignored in respect of Bitcoin payments, and thus OP_RETURNhas been used in the prior art as a mechanism for conveying non-paymentrelated data via the blockchain.

Bob now prepares the following transaction:

Tx3

In:

-   -   amount: A    -   ref: Tx2:Out2    -   unlocked by: <Bob's signature> OP_5

Out: . . .

In principle, after OP_RETURN one could store a hash indexed in a DHT,so that arbitrarily long intermediate results can be passed betweentransactions. Obviously, in this example Alice trusts that Bob willprepare Tx3 as above, so that the computation can be completedsuccessfully. A simple extension could require that Tx2:Out2 is signedby both Alice and Bob, so that Alice can verify that Bob has preparedthe correct transaction. However, Bob could indefinitely delay theexecution by refusing either to prepare the transaction or to sign it.Alice could also prepare Tx3, send it to Bob, and avoid to store dataafter OP_RETURN. It is noted that this approach requires one to wait forconfirmation that each chunk of computation is in the blockchain.

Detailed examples of these two implementations of the underlyingtechnique are provided below, and in reference to the accompanyingfigures. The following description is organized as follows:

-   -   “Embodiment 1” describes the first approach that uses only two        transactions; multiple inputs and outputs are manipulated    -   “Embodiment 2” describes the alternative approach which “links”        or chains multiple transactions to achieve the same technical        effect. It is worth noting that combinations of the two        approaches are also possible.

To illustrate the use of both embodiments, we now consider the followingexample which evaluates a function ƒ(x,y,z) defined as follows

ƒ(x,y,z)=(x·y+z)·x

We (or the compiler) express ƒ(x,y,z) as a sum of simple functions

g ₁(x,y)=x·y

g ₂(g ₁(x,y),z)=g ₁(x,y)+z

ƒ(g ₂(g ₁(x,y),z),x)=g ₂(g ₁(x,y),z)·x

In both embodiments, the variables x, y, and z, which represent thearguments of g₁ and g₂, will be contained in transaction unlockingscripts, while the functions g₁ and g₂ themselves will be contained inlocking scripts. Therefore, hereafter, we will use the terms “function”and “locking script” interchangeably. In particular, and will be in thescript that unlocks the locking script containing g₁. Similarly, g₁(x,y)and z will be in the script that unlocks the locking script containingg₂.

In the subsequent section of this paper, the example we use include theop_codes OP_ADD and PrO_MULT. These identifiers represent the arithmeticoperations addition (+) and multiplication (·) respectively. Theop_codes OP_X, OP_Y, and OP_Z represent the variables x, y, and z. Thesymbols G₁ and G₂ represent the values at the top of the stack after thelocking scripts corresponding to g₁ and g₂ will have been unlocked.OP_ADD is an op_code which forms part of the Bitcoin script language. Weuse the term “PrO_MULT”, short for “primitive operator” to refer to anoperation which can be executed to perform a multiplication operation.In the current version of Bitcoin, the op_codes for multiplication (suchas OP_MUL, OP_2MUL) are disabled and so PrO_MULT could be acustom-defined operation to provide that currently disabledfunctionality. Of course, if the OP_MUL etc opcodes are re-enabled thenthese could be used instead. Thus, the present invention can be usedsolely with functions that use standard (enabled) opcodes, and theimplementation details of custom-built operators are not part of, orrelevant to, the present invention. Therefore, details relating to howPrO_MULT could be implemented are not necessary to the understanding ofthe present invention, and have not been included herein for the sake ofclarity.

The example presented herein corresponds to the execution of a verysimple smart contract in which funds are transferred from Alice to Bob,conditional on the successful execution of a long script. The scriptinputs are provided by Bob, and one can envisage two possible maliciousbehaviours. Firstly, Bob might provide incorrect inputs such that thescript executes successfully and the funds are transferred to him.However, when the transaction(s) is/are stored in the blockchain, theinputs become publicly available allowing Alice to dispute the contract.Secondly, if Bob has any reason to refuse the transfer from Alice, hemight decide to stall the transaction indefinitely, therefore preventingthe execution of the contract. In the most straightforward scenario,Alice must simply trust that Bob will not stall the execution of thecontract and that he will provide the correct inputs. Additionalsecurity mechanisms may be utilised in conjunction with the inventiveconcept to enhance security.

Embodiment 1: Splitting Scripts into Multiple Inputs and Outputs

FIGS. 1, 9 a and 9 b illustrate the chain of transactions and thesequential steps involved in a multiple inputs/outputs approach ofembodiment 1. Tx1 contains a set of Unspent Transaction Outputs (UTXOs)that will be consumed by Tx2. The construction of Tx2 proceedsincrementally, step by step. At each phase, an (automated software)agent presents an unlocking script to one UTXO of Tx1. The agentvalidates Tx2, reads the value(s) on top of the stack, and prepares anew unlocking script. The automated generation of blockchaintransactions and scripts is known in the art and therefore not explainedherein.

The agent may use the information obtained from the stack in theprevious step (or from earlier steps), and presents this new unlockingscript to another UTXO contained within Tx1. Tx2 is broadcasted when allthe necessary steps are accomplished for the present task.

Advantageously, this technique decouples the functions contained in thelocking scripts of Tx1 from the arguments contained in the unlockingscripts provided by Tx2. Functions become immutable once Tx1 has beenadded to the blockchain and verified. In addition, at this stage, thefunction arguments (inputs) may even be unknown. They are revealed onlylater, when Tx2 is prepared. This may be advantageous and provideenhanced security.

The sequence of steps for embodiment 1 is shown in FIG. 1 , FIGS. 9 aand 9 b and can be described as follows:

-   Step 0: Alice submits transaction 1 (as shown in FIG. 1 ) to the    Bitcoin network.-   Step 1: Bob prepares an initial version of transaction 2-   Step 3: Bob presents <Bob's signature><OP_X><OP_Y><Redeem script 1>    to output0. Bob validates transaction 2, reads the value G₁ on top    of the stack, but does not broadcast transaction 2.-   Step 4: Bob presents <Bob's signature><G₁><OP_Z> <Redeem script 2>    to output1. Bob validates transaction 2, reads the value G₂ on top    of the stack, but does not broadcast transaction 2.-   Step 5: Bob presents <Bob's signature><G₂><OP_X><Redeem script 3> to    output2. Bob validates transaction 2 and broadcasts it.

For the sake of simplicity, we do not provide extensive detailsregarding Tx1's inputs and Tx2's output(s). FIG. 2 shows Transaction 1(Tx1). FIG. 3 shows transaction 2 (Tx2).

Embodiment 2: Splitting Scripts in Multiple Transactions

The second embodiment uses blockchain transactions to compose functions(see FIG. 4 ). This approach is similar in principle to the previousembodiment. However, during the validation phase, the agent reads thevalue(s) on top of the stack, and adds it/them after an OP_RETURN asexplained above.

FIGS. 5 to 8 show transactions 1, 2, 3, and 4 in accordance with anillustrative version of embodiment 2.

It should be noted that the above-mentioned embodiments illustraterather than limit the invention, and that those skilled in the art willbe capable of designing many alternative embodiments without departingfrom the scope of the invention as defined by the appended claims. Inthe claims, any reference signs placed in parentheses shall not beconstrued as limiting the claims. The word “comprising” and “comprises”,and the like, does not exclude the presence of elements or steps otherthan those listed in any claim or the specification as a whole. In thepresent specification, “comprises” means “includes or consists of” and“comprising” means “including or consisting of”. The singular referenceof an element does not exclude the plural reference of such elements andvice-versa. The invention may be implemented by means of hardwarecomprising several distinct elements, and by means of a suitablyprogrammed computer. In a device claim enumerating several means,several of these means may be embodied by one and the same item ofhardware.

The mere fact that certain measures are recited in mutually differentdependent claims does not indicate that a combination of these measurescannot be used to advantage.

1-16. (canceled)
 17. A method comprising: obtaining an unlocking script(ULS2) associated with an input (In2), the unlocking script (ULS2)comprising a result from a stack-based data structure, wherein theresult is based on an output from a first blockchain transaction (Tx1)resulting from a different unlocking script (ULS1) associated with adifferent output (In1), the unlocking script (ULS2) and unlocking script(ULS1) provided within a blockchain transaction (Tx2); and presentingthe unlocking script (ULS2) to an associated locking script (LS2) suchthat the result from the stack-based data structure is provided as inputto the locking script (LS2), wherein the locking script (LS2) isprovided within a different blockchain transaction (Tx1).
 18. The methodaccording to claim 17, wherein a blockchain including the blockchaintransaction is of a consensus-based, distributed, electronic ledger. 19.The method according to claim 17, further comprising: using a data itemin execution of a calculation or sequence of instructions providedwithin a different locking script (LS1) associated with the differentunlocking script (ULS1).
 20. The method according to claim 19, wherein:the result is provided as metadata within the unlocking script (ULS2).21. The method according to claim 17, wherein: the result from thestack-based data structure is provided as input to further lockingscript (LS2), wherein the different locking script (LS1) and the lockingscript (LS2) are provided in association with different outputs withinthe different blockchain transaction (Tx1).
 22. The method according toclaim 17, further comprising: obtaining the result from the stack-basedstructure as metadata within the unlocking script (ULS2).
 23. The methodaccording to claim 17, further comprising: validating one or more of theblockchain transaction (Tx2) and the different transaction (Tx1) togenerate the result from the stack-based structure.
 24. The methodaccording to claim 17, wherein validating the one or more of theblockchain transaction (Tx2) and the different transaction (Tx1)includes: obtaining, by an agent, a value from the stack-based datastructure; and adding, by the agent, the value to a script opcode. 25.The method according to claim 17, wherein: obtaining the differentunlocking script (ULS1) and the unlocking script (ULS2) in associationwith different inputs (In1 In2) within the blockchain transaction (Tx2).26. The method according to claim 17, wherein: the locking script (LS1)and the further locking script (LS2) are provided in association withdifferent outputs within the different blockchain transaction (Tx1). 27.The method according to claim 17, wherein: presenting the unlockingscript (ULS2) to the locking script (LS2) provides a further result onthe stack-based structure.
 28. The method according to claim 17, furthercomprising: using a blockchain client to obtain the result from thestack-based structure.
 29. The method according to claim 17, and furthercomprising: submitting one or more of the blockchain transaction (Tx2)and different blockchain transaction (Tx1) to a blockchain network. 30.The method according to claim 17, wherein: the blockchain transaction(Tx2) is modified to include a second input (ln2).
 31. The methodaccording to claim 17, and further comprising: using the method tocompute a final result, and using the final result to control a processperformed off the blockchain.
 32. A computer-implemented systemcomprising: a processor; and memory storing non-transitorycomputer-readable instructions that, when executed by the processor,cause the processor to at least: obtain an unlocking script (ULS2)associated with an input (In2), the unlocking script (ULS2) comprising aresult from a stack-based data structure, wherein the result is based onan output from a first blockchain transaction (Tx1) resulting from adifferent unlocking script (ULS1) associated with a different output(In1), the unlocking script (ULS2) and unlocking script (ULS1) providedwithin a blockchain transaction (Tx2); and present the unlocking script(ULS2) to an associated locking script (LS2) such that the result fromthe stack-based data structure is provided as input to the lockingscript (LS2), wherein the locking script (LS2) is provided within adifferent blockchain transaction (Tx1).
 33. The computer-implementedsystem according to claim 32, wherein the instructions include furtherinstructions that cause the processor to: use a data item in theexecution of a calculation or sequence of instructions provided within adifferent locking script (LS1) associated with the different unlockingscript (ULS1).
 34. The computer-implemented system according to claim32, wherein: the result from the stack-based data structure is providedas input to further locking script (LS2), wherein the different lockingscript (LS1) and the locking script (LS2) are provided in associationwith different outputs within the different blockchain transaction(Tx1).
 35. The computer-implemented system according to claim 32,wherein the instructions include further instructions that cause theprocessor to: obtain the result from the stack-based structure asmetadata within the unlocking script (ULS2); and obtain the differentunlocking script (ULS1) and the unlocking script (ULS2) in associationwith different inputs (In1 In2) within the blockchain transaction (Tx2).